When you have created a virtual server and it is available to the network, you can mount the file system by using the Network File System (NFS) for UNIX clients.
The process described above enables the system for NFS clients, but the virtual server is not yet available to Windows clients, and the file system cannot yet be accessed by using Windows file sharing. With the Common Internet File System (CIFS), users with different platforms and computers can share files. Your next step is to make the virtual server available to Windows clients and enable file sharing. Virtual servers that serve CIFS clients must be members of a CIFS domain.
Windows network clients that need to use file server resources must be able to locate the file server on the network. CIFS does this with NetBIOS names. A NetBIOS name is a case-insensitive, 16-character name that uniquely identifies a host on a subnetwork. You must provide a unique NetBIOS name for each of the CIFS virtual servers you define. This name is used when CIFS clients connect to the file server.
The Windows Internet Name Service (WINS) was created as an extension to the original NetBIOS naming specification. WINS performs the same basic function as a DNS server; that is, it accepts name registrations from hosts that must register or publish their network services. It resolves names into IP addresses for hosts that need to access those resources. WINS servers also communicate with each other and exchange host information so that hosts in one subnet can be known in another subnet. WINS does, however, complicate the name registration process for hosts.
The NetBIOS protocol partitions groups of servers into multiple subnets, thus requiring the client to know the IP address of the host if it exists on another subnet. The WINS server provides ways to look up server IP addresses for servers that are on a separate subnet. The NetBIOS node types determine the process by which the original NetBIOS protocol and WINS are used to locate a server.
Four different mechanisms are currently in place to register NetBIOS host names on a network. These are described as follows:
The B or Broadcast NetBIOS Node Type is a purely broadcast mechanism in which the host announces its name to the subnet.
The P or Peer NetBIOS Node Type is a WINS mechanism in which the host is configured with the name of a WINS server and informs the WINS server of its intent to use a NetBIOS host name.
The H or Hybrid NetBIOS Node Type is a mixed-mode announcement mechanism in which the host first contacts the WINS server and negotiates the use of its NetBIOS name and then broadcasts its name to the local subnet.
The M or Microsoft NetBIOS Node Type is another mixed-mode announcement mechanism, in which the host first broadcasts its name to the local subnet and then contacts a WINS server and negotiates for use of its NetBIOS host name.
The default NetBIOS Node Type is M.
Note: A WINS Server IP address is required if any virtual servers are using the M, H, or P NetBIOS node types. Without a WINS Server IP address, virtual servers can have only a B NetBIOS node type.
See the Windows documentation for further information about WINS and NetBIOS.
Each CIFS virtual server must participate in the Windows NT Domain Security model and have a corresponding account on the Windows Primary Domain Controller for the domain it participates in. Also, to prevent users of one CIFS virtual server in one domain from seeing another CIFS virtual server in another domain, NetBIOS name announcements must be limited to the subnet in which the virtual server is located. To accomplish this, NetBIOS name announcements are limited by the subnet mask that is specified in the management interface when a virtual interface is created.
To define a CIFS domain, you need to have the following information available.
| Domain name | |
| Primary Domain Controller (PDC) name | |
| Primary Domain Controller IP address | |
| WINS Server IP address (optional, but recommended) | |
| Backup Domain Controller (BDC) 1 name (optional) | |
| Backup Domain Controller 1 IP address (optional) | |
| Backup Domain Controller 2 name (optional) | |
| Backup Domain Controller 2 IP address (optional) | |
| Backup Domain Controller 3 name (optional) | |
| Backup Domain Controller 3 IP address (optional) | |
| Backup Domain Controller 4 name (optional) | |
| Backup Domain Controller 4 IP address (optional) |
To enable file sharing to Windows clients, you must complete the following tasks:
Define a CIFS domain in which the virtual server resides.
Define domains that are visible to the virtual server.
Enable the virtual server for CIFS.
Create CIFS shares.
Use the spinaccess cifs domains new command to create and configure a CIFS domain.
A CIFS server must exist within a configured domain. By configuring the CIFS domains, you inform the SpinServer of the Windows NT or Windows 2000 domains that exist on the network and that have access to the SpinServer.
Note: Regardless of the case used to enter the new domain name, CIFS domain names are converted to all uppercase when they are created.
Use the spinaccess cifs domains new command to create a new CIFS domain. The command has the following syntax:
spinaccess cifs domains new -domainname CIFS_domain_name [-winsip WINS_IP_address] -pdcname primary_domain_controller_name -pdcip primary_domain_controller_IP_address [-bdcname1 backup_domain_controller_name_1 -bdcip1 backup_domain_controller_IP_address_1] [-kerbconf Kerberos_configuration_name]
The following example creates a new CIFS domain named ENG. The domain's WINS server has an IP address of 10.1.1.116. The primary domain controller is named STORM and has an IP address of 10.1.1.116. The backup domain controller is named RAIN and has an IP address of 10.1.1.118. No Kerberos configuration is specified for the domain.
spinserver::> spinaccess cifs domains new -domainname ENG -winsip 10.1.1.116 -pdcname STORM -pdcip 10.1.1.116 -bdcname1 RAIN -bdcip1 10.1.1.118
Note: If you specify backup domain controllers, the BDC fields with the lowest values must be entered first. For example, if you have one backup domain controller, enter -bdcname1 and -bdcip1. If you have two, enter -bdcname1, -bdcip1, -bdcname2, and -bdcip2. If you have three, enter -bdcname1, -bdcip1, -bdcname2, -bdcip2, -bdcname3, and -bdcip3. All must be entered before a fourth backup domain controller is specified.
Use the spinaccess cifs domains show command to display information about CIFS domains.
To display general configuration information about all CIFS domains, do not use the parameter. To display information about one specific CIFS domain, use the command with the parameter.
The following information about the CIFS domains is displayed by the system when you do not specify a particular domain: Domain name, PDC name, and Kerberos configuration name. When you specify a domain, the following additional information is displayed: WINS, PDC name and IP address, Kerberos configuration name, and BDC names and IP addresses.
The command has the following syntax:
spinaccess cifs domains show [-domainname domain_name]
The following example displays information about a CIFS domain named ENG.
spinserver::> spinaccess cifs domains show -domainname ENG Domain ENG Windows SID S-1-5-21-393965755-660102513-868425949 WINS 10.1.1.41 PDC Name XAVIER PDC IP 10.1.1.41 Kerberos Configuration Name example.com BDC 1 Name MAGNETO BDC 1 IP 10.1.1.42 BDC 2 Name BDC 2 IP BDC 3 Name BDC 3 IP BDC 4 Name BDC 4 IP
Use the spinaccess cifs domains modify command to modify a CIFS domain. The command has the following syntax:
spinaccess cifs domains modify -domainname CIFS_domain_name [-winsip WINS_IP_address] -pdcname primary_domain_controller_name -pdcip primary_domain_controller_IP_address [-bdcname1 backup_domain_controller_name] [-bdcip1 backup_domain_controller_IP_address] [-kerbconf Kerberos_configuration_name]
Note: The -winsip parameter is optional. When a virtual server is added to the domain, it must be of type B if the domain does not have a WINS IP address. If you create a CIFS domain with a WINS IP address and add a virtual server with a node type that is not B (that is, M, P, or H), the domain must have a WINS IP address if modified.
Note: The SpinServer supports only pre-Windows 2000 domain names.
The following example modifies a CIFS domain named ENG. The domain's WINS server has an IP address of 10.1.1.11. The primary domain controller is named STORM and has an IP address of 10.1.1.11. The backup domain controller is named RAIN and has an IP address of 10.1.1.117.
spinserver::> spinaccess cifs domains modify -domainname ENG -winsip 10.1.1.11 -pdcname STORM -pdcip 10.1.1.11 -bdcname1 RAIN -bdcip1 10.1.1.117
If you need to remove a backup domain controller (BDC) from a CIFS domain, use the spinaccess cifs domains removebdc command. The command has the following syntax:
spinaccess cifs domains removebdc -domainname domain_name -bdcs list_of_BDCs
The following example removes a BDC named FOG from a CIFS domain named ENG:
spinserver::> spinaccess cifs domains removebdc -domainname ENG -bdcs FOG
To remove a CIFS domain from a system, use the spinaccess cifs domains delete command. A CIFS domain cannot be deleted if there are any CIFS servers within the CIFS domain (that is, CIFS virtual servers that were created by specifying the CIFS domain) or if a CIFS server lists the domain as visible.
Note: A cluster is limited to 4,096 domains. However, deleting a domain does not free up that space in the maximum domain list. For security reasons, all domain information ever entered into the cluster is kept indefinitely.
The command has the following syntax:
spinaccess cifs domains delete -domainname domain_name
The following example deletes a CIFS domain named ENG.
spinserver::> spinaccess cifs domains delete -domainname ENG
In some circumstances it can be necessary to rename a CIFS domain without changing the domain's SID. Use the tools cifs domains rename command to rename a CIFS domain.
| Caution: |
|
Changing the name of a CIFS domain improperly can result in the CIFS domain becoming inaccessible. Use extreme care when running this command. |
The command has the following syntax:
tools cifs domains rename -domainname domain_name -newname new_domain_name
The following example changes the name of a CIFS domain from WATERMELON to CANTALOUPE.
spinserver::> tools cifs domains rename -domainname WATERMELON -newname CANTALOUPE
After defining and creating a CIFS domain, you must enable a virtual server for CIFS.
A CIFS server consists of a virtual server, one or more virtual interfaces, and information about the server's domain. When creating a CIFS server, you must specify the NetBIOS node type, which determines how the server registers itself on the Windows Network.
If a domain is not defined to be visible to a virtual server, the CIFS virtual server ignores the domain, even if that domain has a Windows NT trust relationship with the CIFS virtual server's primary domain. Even if the Access Control List (ACL) on a file contains an entry from another domain, CIFS does not allow the domain to be considered during the access check because domains that are not defined as visible to the virtual server are masked.
The same NetBIOS name can be used on different CIFS domains.
The maximum number of CIFS servers per cluster is eight; the maximum number of CIFS shares per CIFS server is 128.
Use the spinaccess cifs servers new command to enable a server for CIFS by configuring it and defining its domain visibility list. The command has the following syntax:
spinaccess cifs servers new -vsname virtual_server_name -nbname NetBIOS_name -visibledomains [domain_list] -domainname domain_name -nodetype {H | M | P | B} -usekerberos {Yes | No} [-kerbprivuser Kerberos_user_name -kerbprivpass Kerberos_password]
The following example enables a CIFS server:
spinserver::> spinaccess cifs servers new -vsname VS1 -nbname NB1 -visibledomains [MARKETING, EXE] -domainname ENG -nodetype M -usekerberos No
where
VS1 is the name of the virtual server. This name must already exist as a virtual server that was created by using the vservers servers new command.
NB1 is the NetBIOS name for the virtual server. The server created is available within the Windows network as this name. In the domain, there must be a machine account with this name in the domain that has not been used by some other machine or virtual server.
[MARKETING, EXE] are the names of the domains that are visible to the virtual server named VS1. The virtual server's own domain is always included in the visible domain list that is displayed. By default, the visible domain list includes all domains that have been defined for the for the SpinServer.
ENG is the name of the CIFS domain for this server. This must be the name of a domain that was created by using the spinaccess cifs domains new command.
M is the NetBIOS node type for this virtual server. Valid values are H, M, P, and B. If you have a WINS server defined for the domain, use M. If you do not have a WINS server defined, use B. If you do not enter a value for the -nodetype parameter, the node type defaults to M.
Note: See RFC 1001 and 1002 for additional information about NetBIOS node types.
No specifies that this server is not to use Kerberos authentication.
Use the spinaccess cifs servers show command to display information about CIFS servers. To display general configuration information about all CIFS servers, do not use the parameter. To display information about a specific CIFS server, use the command with the parameter. The command displays the following information:
Virtual server name
List of visible domains
NetBIOS name
Domain name
Virtual interface names
NetBIOS type
Whether or not Kerberos is enabled
Kerberos configuration name
Kerberos Service Principal Name
The command has the following syntax:
spinaccess cifs servers show [-vsname virtual_server_name]
The following example displays information about a CIFS server on a virtual server named VS1.
spinserver::> spinaccess cifs servers show -vsname VS1 Virtual Server VS1 NetBios Name VS1 Domain ENG Visible Domains CIFSLAND, ENG, SLAB, SUPPORT Interfaces Server2:Data, Server1:Data Type P Kerberos Enabled Yes Kerberos Configuration Name example.com Service Principal Name HOST/SERVER1@EXAMPLE.COM
To remove a CIFS server from a system, use the spinaccess cifs servers delete command. Deleting the CIFS server from the system does not delete the virtual server; it removes only the ability to access the virtual server via CIFS. Deleting a CIFS virtual server deletes all the CIFS shares associated with that virtual server. The command has the following syntax:
spinaccess cifs servers delete -vsname virtual_server_name
Note: Any defined CIFS shares on the server are automatically deleted when you delete the server.
Note: If you delete a CIFS server that is configured to use Kerberos, or is changed to use a different Service Principal Name (SPN), its original service principal is not automatically deleted from or disabled in the Kerberos realm. If you no longer need the service principal, it is recommended that you manually delete or disable the principal. This requires the Kerberos realm administrator's user name and password.
The following example deletes a CIFS server associated with a virtual server named VS1:
spinserver::> spinaccess cifs servers delete -vsname VS1
CIFS virtual servers must be members of a domain. They have Machine Trust Accounts on the Primary Domain Controller. Just like normal user accounts, Machine Trust Accounts have passwords that are known only to the machine using the account. For enhanced security, the password for the machine is randomly generated and cannot be specified by the system administrator.
The SpinServer system automatically changes the Machine Trust Account Passwords once a week. However, you have the option to force an immediate password change for a virtual server if you suspect a security breach or are trying to diagnose a problem. When issuing the spinaccess cifs servers forcepasswordchange command, you must specify a virtual server, which contacts its Primary Domain Controller and changes its Machine Trust Account password.
Use the spinaccess cifs servers forcepasswordchange command to force a password change for a CIFS server in a system. The command has the following syntax:
spinaccess cifs servers forcepasswordchange -vsname virtual_server_name
The following example forces a password change for a CIFS server associated with a virtual server named VS1:
spinserver::> spinaccess cifs servers forcepasswordchange -vsname VS1
If the Kerberos configuration on a CIFS server becomes corrupted, use the spinaccess cifs servers resetpassword command to reset the server's Kerberos password. The command has the following syntax:
spinaccess cifs servers resetpassword -vsname virtual_server_name -uname admin_user_name -passwd admin_password
Note: The administrator's password appears in clear text on the CLI; however, the GUI masks the password. To protect the security of the password, it is recommended that you use the GUI to issue this command.
The following command example resets the Kerberos password for a CIFS server named VS1. The administrative user's name is admin, with the password S3cr3t.
spinserver::> spinaccess cifs servers resetpassword -vsname VS1 -uname admin -passwd S3cr3t
The spinaccess cifs servers modify command replaces the existing list of visible domains. If you remove a domain from the list of visible domains for a virtual server, any access control list (ACL) entries that specify a user or group from the removed domain no longer has access to the files. The entry is not removed from the ACL, but it is not considered during the access check. The command has the following syntax:
spinaccess cifs servers modify -vsname virtual_server_name -visibledomains [list_of_domains] [-nodetype {H | M | P | B}] [-kerbprivuser Kerberos_user_name -kerbprivpass Kerberos_password]
The following example modifies a CIFS server to make the MARKETING domain visible to a virtual server named VS1. By default, the visible domain list includes all domains that have been defined for the virtual server. In this example, the EXE domain is removed from the list of visible domains for the server.
spinserver::> spinaccess cifs servers modify -vsname VS1 -visibledomains MARKETING
After the necessary CIFS virtual server is created, the virtual server is viewable on the Windows Network, but no data is shared yet. To share data, a CIFS share must be created. The share name must be unique for the virtual server. A CIFS share is a named access point in a VFS that enables CIFS clients to view, browse, and manipulate files on a file server.
To define a CIFS share you create and configure a CIFS share by using the spinaccess cifs shares new command. Defining a share determines the directory within the file system that is accessible to Windows clients.
Note: A share is tied to its virtual server and CIFS server and is deleted if either the virtual server or the CIFS server to which it is attached is removed from the system.
To share data, a CIFS share must be created. Up to 128 shares can be created on a single virtual server. Use the spinaccess cifs shares new command to create a CIFS share. When you create a share, you can specify its properties, including the following:
Dynamic shares. In a dynamic share, the share's name and path can be generated by substituting the user's name and domain with the %u and %d variables, respectively, specified as the value of the -path parameter. For instance, if a dynamic share is defined as /user/%u, a user logged on as bill sees the path as /user/bill. Similarly, if a dynamic share is defined with a name of %d_%u, a user logged on as barbara from a domain named FIN sees the share as FIN_barbara. You can create a dynamic share by specifying the -shareprops parameter with the dynpath and dynshare values.
Mode-bit inheritance. With mode-bit inheritance, new files and directories inherit the UNIX mode bits of the parent directory. For instance, if a new file is created in a directory that has a mode-bit setting of 777, then the new file automatically receives a mode-bit setting of 777. On a single CIFS share, you can specify either mode-bit inheritance with the -shareprops mbinherit parameter or explicit mode-bit setting with the -dirmodebits and -filemodebits parameters. You cannot specify both types of mode-bit setting on the same share.
Opportunistic locks. By default, shares use opportunistic locks, also known as client-side caching. Some applications do not work well when oplocks are enabled. In particular, database applications such as Microsoft Access are vulnerable to corruption when oplocks are enabled. An advantage of shares is that a single path can be shared multiple times, with each share having different properties. For instance, if a path named /dept/finance contains both a database and other types of files, you can create two shares to it, one with oplocks disabled for safe database access and one with oplocks enabled for client-side caching.
The command has the following syntax:
spinaccess cifs shares new -vsname virtual_server_name -sharename share_name -path directory_path [-shareprops share_properties] [-dirmodebits directory_mode_bits] [-filemodebits file_mode_bits] [-remark description]
The -shareprops parameter specifies any special properties for the share. Multiple values can be specified for a share. Possible values include the following:
dynpath—This specifies that the share's path name is dynamic. For a full dynamic share, specify both the dynpath and dynshare values for this parameter.
dynshare—This specifies that the share name is dynamic. For a full dynamic share, specify both the dynpath and dynshare values for this parameter
mbinherit—This specifies that new files and directories inherit the mode bits of the parent directory.
oplocks—This specifies whether the share uses opportunistic locks.
The -dirmodebits and -filemodebits parameters specify UNIX mode bits for new directories and files, respectively. These mode bits are used only when a directory or file is created. Accessing an existing directory or file through multiple CIFS shares that have different values for these parameters returns consistent permissions and access rights. For instance, assume you have a share named share1 that has file mode bits of 777 and a share named share2 that has file mode bits of 755, and that these shares overlap (that is, can access the same directories). If you create a file named \\server\share1\foo, the mode bits on that file are 777. If you create a file named \\server\share2\bar, the mode bits on that file are 755. If a user accesses the file named foo through the path \\server\share2\foo, the access permissions are 777; if a user accesses the file named bar through the path \\server\share1\bar, the access permissions are 755
The -remark parameter specifies a descriptive remark up to 255 characters long. If there is a space in the descriptive remark, the entire string must be quoted (for example, "This is a share").
The following example creates a CIFS share named SHARE1 on a virtual server named vs1. Its directory path is /development/engineering. Opportunistic locks are specified on the share, and mode bits are explicitly set as 777 on directories and 775 on files.
spinserver::> spinaccess cifs shares new -vsname vs1 -sharename SHARE1 -path /development/engineering -shareprops oplocks -dirmodebits 777 -filemodebits 775
The following example creates a CIFS share named SHARE2 on a virtual server named vs1. Its directory path is /dept/system, and mode-bit inheritance is set.
spinserver::> spinaccess cifs shares new -vsname vs1 -sharename SHARE2 -path /dept/system -shareprops mbinherit
To review the list of CIFS shares, use the spinaccess cifs shares show command. To display general configuration information about all CIFS shares, do not use the parameters. To display information about one specific CIFS share, use the command with the parameters. The command displays the following information:
Virtual server name
NetBIOS name of the virtual server
Share name
Directory path
Share properties
Directory mode bits
File mode bits
Share remark
Share status
The command has the following syntax:
spinaccess cifs shares show [-vsname virtual_server_name -sharename share_name]
The following example displays information about a CIFS share named SYSTEM on a virtual server named VS1.
spinserver::> spinaccess cifs shares show -vsname VS1 -sharename SYSTEM Virtual Server VS1 Share Name SYSTEM Server NetBios Name VS1 Path /system Share Properties oplocks Dir Mode Bits 755 File Mode Bits 755 Remark Status OK
Use the spinaccess cifs shares modify command to modify a CIFS share. The command has the following syntax:
spinaccess cifs shares modify -vsname virtual_server_name -sharename share_name [-shareprops share_properties] [-dirmodebits directory_mode_bits] [-filemodebits file_mode_bits] [-remark description]
The following example modifies a CIFS share named SHARE1 on a virtual server named vs1. Mode bits are explicitly set as 755 on directories and 644 on files.
spinserver::> spinaccess cifs shares modify -vsname vs1 -sharename SHARE1 -dirmodebits 755 -filemodebits 644
To remove a CIFS share from a system, use the spinaccess cifs shares delete command. The command has the following syntax:
spinaccess cifs shares delete -vsname virtual_server_name -sharename share_name
Note: Deleting CIFS shares does not delete the data that exists in the VFS.
The following example deletes a CIFS share named ENG_BILL on a virtual server named VS1:
spinserver::> spinaccess cifs shares delete -vsname VS1 -sharename ENG_BILL
Most file systems include a superuser account. Such an account enables system administrators to modify files and their attributes without reference to the usual file permission system. This facility is needed for many management tasks including software installation, recovery from user error (for example, errors resulting in users locking themselves out of their files), and retrieval of files owned by obsolete users.
In the SpinServer system, the granting of superuser privilege is based on the user, not on group membership.
Because each virtual server has an independent user namespace, the privileged superuser and host lists are qualified by the virtual server. This enables the administrator to delegate superuser responsibilities at the virtual server level.
To grant superuser access, use the spinaccess superuser cifs new command to add a CIFS user to the list of CIFS users that are eligible for superuser access. The command has the following syntax:
spinaccess superuser cifs new -vsname virtual_server_name -domainname domain_name -username user_name
The following example adds a CIFS user named tom to the eligibility list for superuser access in the domain named ENG on the virtual server named VS1.
spinserver::> spinaccess superuser cifs new -vsname VS1 -domainname ENG -username tom
To display the list of CIFS users that are eligible for superuser access, use the spinaccess superuser cifs show command, as in the following example.
spinserver::> spinaccess superuser cifs show Virtual Server Domain Name User Name VS1 ENG louise VS1 ENG myrtle VS1 ENG tom
To remove a CIFS user from the list of CIFS users that are eligible for superuser access, use the spinaccess superuser cifs delete command. The command has the following syntax:
spinaccess superuser cifs delete -vsname virtual_server_name -domainname domain_name -username user_name
The following example removes a CIFS user named tom from the list of eligibility for superuser access to a virtual server named VS1 in a domain named ENG.
spinserver::> spinaccess superuser cifs delete -vsname VS1 -domainname ENG -username tom
To create an IP address block for superuser access, use the spinaccess superuser privilegedips new command. The client must connect from this IP address block to be eligible for superuser access. Privileged IP addresses apply to both NFS and CIFS, although privileged users must be CIFS users. The command has the following syntax:
spinaccess superuser privilegedips new -vsname virtual_server_name -address IP_address -netmask netmask
The following example creates a superuser IP address block.
spinserver::> spinaccess superuser privilegedips new -vsname VS1 -address 192.168.0.0 -netmask 255.255.0.0
where
VS1 is the name of the virtual server. Each privileged IP block applies to one and only one virtual server. This parameter specifies the virtual server to which the specified privileged IP address block applies.
192.168.0.0 is the network address that must be matched for the user to be eligible for superuser access.
255.255.0.0 is the network mask that is applied to the client's IP address before it is compared to the network address that determines superuser eligibility.
To display the superuser IP address block, use the spinaccess superuser privilegedips show command. The following example displays all superuser IP address blocks.
spinserver::> spinaccess superuser privilegedips show Virtual Server Network Address Hostmask VS1 10.3.4.241 255.255.255.255 VS1 10.1.0.0 255.255.0.0
To remove an IP address block from the list of network addresses that are eligible for superuser access, use the spinaccess superuser privilegedips delete command. The command has the following syntax:
spinaccess superuser privilegedips delete -vsname virtual_server_name -address IP_address -netmask netmask
The following example removes an IP address block from the list of network addresses that are eligible for superuser access.
spinserver::> spinaccess superuser privilegedips delete -vsname VS1 -address 192.168.0.0 -netmask 255.255.0.0
where
VS1 is the name given to the virtual server. Each privileged IP block applies to one and only one virtual server. This parameter specifies the virtual server to which the specified privileged IP address block applies.
192.168.0.0 is the network address that must be matched for the user to be eligible for superuser access.
255.255.0.0 is the network mask that is applied to the client's IP address before it is compared to the network address that determines superuser eligibility.
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.